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ABSTRACT 

We present a quantitative comparison between software features of the defacto standard X-ray 
spectral analysis tool, XSPEC and ISIS the Interactive Spectral Interpretation System. Our emphasis 
is on customized analysis, with ISIS offered as a strong example of configurable software. While noting 
that XSPEC has been of immense value to astronomers, and that its scientific core is moderately 
extensible — most commonly via the inclusion of user contributed "local models" — we identify a series 
of limitations with its use beyond conventional spectral modeling. We argue that from the viewpoint 
of the astronomical user, the XSPEC internal structure presents a Black Box Problem, with many 
of its important features hidden from the top-level interface, thus discouraging user customization. 
Drawing from examples in custom modeling, numerical analysis, parallel computation, visualization, 
data management, and automated code generation, we show how a numerically scriptable, modular, 
and extensible analysis platform such as ISIS facilitates many forms of advanced astrophysical inquiry. 
Subject headings: Data Analysis and Techniques 



1. INTRODUCTION 

The pursuit of science pushes not only the boundaries 
of knowledge, but also the limits of technology used to 
acquire and analyze data from which new knowledge can 
be distilled. In this sense software systems for scien- 
tific analysis are never truly complete, so it is crucial 
that they be extensible. This enables scientists to incor- 
porate custom, experimental codes into the system and 
drive it in directions not yet supported, or perhaps even 
envisioned, by its creators. A corollary is that the mech- 
anisms for and results of the customization should be 
made as simple, powerful, and general as possible, free- 
ing the practitioner to concentrate more on algorithmic 
or scientific concerns and less on the plumbing details of 
a given computational platform. 

This paper compares the extent to which two open- 
source spectral an alysis applicat ions active ly used in as - 
tronomy, XSPEC (lArnaudll!996h and ISIS (lHouckll2002n . 
meet these general criteria. The features of both systems 
are broadly surveyed, with contrasts drawn from a series 
of examples representative of astronomy in practice. A 
heavy emphasis is placed upon the roles of interpreted 
arrays, and the capability to quickly generate and nu- 
merically manipulate them as powerful enablers of anal- 
ysis. The emergent theme is that numerical and archi- 
tectural discontinuities between the internals of XSPEC 
and its controlling TCL interpreter, referred to in the 
large as the Black Box Problem, limit its full exploita- 
tion for scientific tasks that are within the reach of more 
configurable interactive analysis systems. We demon- 
strate the strong modularity and extensible scriptability 
of ISIS and suggest that such open and highly config- 
urable systems offer deeper and wider promise for meet- 
ing the needs of exploratory scientific analysis. 

The latest major versions of ISIS and XSPEC, 1.4.x 
and 12.x respectively, were used in our study. While 



XSPEC 11 remains in wide use (the first public, non- 
beta release of XSPEC 12 was circa 2005), it is more 
difficult to extend with a variety of custom models and 
so in terms of extensibility would compare less favorably 
than does XSPEC 12. 

Guiding our endeavor will be the sense of what a typi- 
cally motivated scientist can achieve in each system with 
reasonable effort. On the premise that a strong program- 
mer can eventually replicate virtually any result using 
nearly any combination of languages or tools, we are 
not concerned with what might in principle be achieved 
from either XSPEC or ISIS but rather what can be 
demonstrated within each. By avoiding hypotheticals we 
aim to transform a potentially open-ended debate into a 
tractable, concrete discussion. Towards this end we de- 
fine working within an application to mean the execution 
of commands, or portions thereof, which only access or 
modify the code or data within the applications address- 
able memory. In this scheme, for example, issuing an 
operating system call from ISIS to spawn an external vi- 
sualization tool would not be "working in ISIS," however 
enlarging its address space by importing a shared object 
module, say to smooth an image in memory, would be. 

We recognize the utility of integrating complemen- 
tary but distinct programs into a single logical entity. 
Building on trust in known tools, it is a sensible scheme 
for managing complexity, fostering reuse, and balancing 
deadlines with goals. Cooperating applications can, with 
sufficient effort, be made to appear as seamless as a sin- 
gle program. One should not, however, equate the act 
of 

• dumping internal state to disk files, spawning a se- 
ries of tools to read this state and create temporary 
data products along the way, then loading these 
new data back into the parent application 
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1 For example, XSPEC 11 supports only local models coded in 
single precision Fortran77. 
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with the ability to 

• invoke a function to operate upon a data structure, 
with both resident in memory. 

In this paper we will argue that the latter offers greater 
immediacy of use, as well as significantly more algorith- 
mic, data, and visualization flexibility. It also addresses 
real scalability concerns as datasets increase in size or 
tasks increase i n time complexity . A stark example of 
this is given in iDavis et al.l (|2005f ). which discusses the 
methods employed to analyze the megas econd observa- 
tion of Cassiopeia A ([Hwang et al.l 12004) by the Chan- 
dra X-Ray Observatory in 2004, which yielded the first 
ever map of electro n acceleration in a supernova remnant 
([Stage et al.ll2006[) . Over 9 million PHA spectra were 
extracted from over 300 million events, with hundreds of 
thousands of spectral fits performed in ISIS to yield arc- 
second resolution spatial maps of plasma temperatures, 
line emission, and Doppler velocities. Custom modules 
were developed to manage the multi-gigabyte files in- 
volved and distribute the spectral extractions and fits 
across a netwo rk of workstation s using the Parallel Vir- 
tual Machine (|Geist et al.lll994D . Based upon the time 
required to extract a single spectrum from these enor- 
mous datasets, with the standard Chandra dmextract 
tool in CIAO (ca. version 3.2), the authors extrapolated 
that the spectral extractions alone would have required 
nearly 10 years had a tool-based approach been taken. In 
contrast, each run through the entire PVM-based analy- 
sis sequence required less than 12 days to complete. 

2. FEATURE SURVEY 

XSPEC and ISIS have been primarily concerned with 
fitting models to ID spectra: a theoretical model of pho- 
ton counts is calculated, convolved with an instrument 
response, and compared to the actual photon counts ob- 
served by the detector, using a given fit statistic (typi- 
cally x 2 ). Each provides mechanisms for indexed loading 
and management of data (observed counts, instrument 
responses, et cetera), as well as the capacity to visually 
inspect, using PGPL0T to construct a variety of 2D plots, 
the data, models, residuals, fit statistics, and so forth. 
While initially targeted for X-ray analysis, both XSPEC 
and ISIS have been utilized in multiple wavebands. The 
primary authors of XSPEC and ISIS are practicing as- 
tronomers with active publication records in the domains 
served by their applications. Both applications are thus 
subject to continuous, rapid, and rigorous scientific vet- 
ting. ISIS and XSPEC update cycles are measured in 
terms of days and weeks, which can be beneficial for users 
under time constraints before their proprietary data go 
public. 

XSPEC is the tool most widely used in X-ray astron- 
omy for spectral fitting; with a legacy spanning more 
than two decades and hundreds of citations, its value 
to the scientific community is beyond question. XSPEC 
bundles more than 50 theoretical models, each of which 
may also be used by external programs simply by link- 
ing to its libraries. The core set of models may be ex- 
tended with either precomputed file-based table models 
or compiled codes. The bulk of compiled XSPEC mod- 
els are coded in Fortran, however as part of a significant 
redesign effort support for custom C and C++ models 
was recently added (ca. 2005). XSPEC was also one of 



the earliest astronomical applications to adopt a widely- 
used, general-purpose scripting language for interactive 
use and batch control; the incorporation of TCL, intro- 
duced in version 10 and stabilized in version 11, provided 
programmability and a clear path to graphical interfaces 
with the Tk widget set. 

ISIS was conceived to support analysis of high- 
resolution Chandra X-Ray gratings spectra, then quickly 
grew into a general-purpose analysis system. ISIS is es- 
sentially a superset of XSPEC, combining all of its mod- 
els (though they are not required for ISIS o peration) an d 
more with the S-Lang scripting language (| Avers! Il996t ) . 
whose mathematical perform ance rivals both co mmer- 
cial p ackages such as MatLab ((Gilat 2004) or IDL (Kline 
1999) as well as the n umerical ex tensions for popular 
open source languages ([Nobld 120071 . JJ]). 

As with XSPEC, users may define custom models in 
compiled code, external tables, or as a string specifying 
simple arithmetic combinations of existing models, but 
ISIS takes it further by also allowing models to be inter- 
preted S-Lang functions; this supports rapid prototyping 
and, because of the high-performance of S-Lang numer- 
ics (SJ2J), need not sacrifice speed for the convenience of 
using an interpreter. XSPEC does not support the use 
of TCL procedures as models. 

The chief means of controlling XSPEC and ISIS in- 
teractively is by textual prompt, with both providing 
VI and EMACS key bindings through GNU readline, 
as well as filename completion and persistent command 
history. XSPEC accepts commands entered in abbre- 
viated form, such as mo for model, but does not auto- 
complete TCL command or variable names from partial 
input. ISIS provides strong auto-completion facilities, al- 
lowing any S-Lang function or variable name to be iden- 
tified from minimal partial input. In addition to the 
command prompt, optional packages providing graphi- 
cal interfa ces, such as the Gtk-ba sed VWhere ( §7.4[) or the 
SAOds9 (|Jove and Mandell f2003) image display module 
( £|7.2p . have been publicly available and utilized within 
ISIS for several years. Graphical ext ensions for XSPEC 
have been discussed in the literature ([Jordan et al.l[l994l ) 
and online, but, ot her than wholly external tools like f v 
([Pence et al.lll997l ). none seem publicly available for use 
within XSPEC proper. 

The XSPEC prompt presents an appealingly simple, 
everything-is-a-command interface, and fosters ease of 
use by offering brief, germane command names, assuming 
sensible defaults, and in some cases transparently com- 
bining multiple operations into one: e.g. loading both 
data and background files with a single command. A 
typical command is shorter and requires less punctua- 
tion in XSPEC, although the auto-completion capability 
of ISIS can compensate for its relative verbosity. In short, 
XSPEC makes it easy to perform many common spectral 
analysis tasks. 

The ISIS prompt was designed to be a proxy S-Lang 
interpreter (Fig. [3]), making ISIS programmable and ex- 
tensible since inception. Its everything-is- a- function phi- 
losophy permeates the implementation and user experi- 
ence, providing, at the cost of a steeper initial learning 
curve, considerable flexibility and power. Consider for il- 
lustration t he Astrophvs ical Plasma Emission Database 
(APED) of lSmith et all (|200ll) . Because ISIS provides 
programmatic access to virtually all of APED, curves 
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Fig. 1. — Ionization fractions for Fe XVII through XXI. 

like those of Fig. [TJ showing the ionization fractions at 
25 temperatures for Fe XVII through XXI, can be cre- 
ated with just a few statements 

temperature = 10 . 0" [6 . : 7 . 2 : . 05] ; 
foreach ion ( [17, 18, 19, 20, 21] ) { 

fraction = ion_frac(Fe, ion, temperature); 

oplot (temperature, fraction); 

} 

either directly from the ISIS prompt or within analysis 
scripts. The importance to X-ray analysis of this sort of 
fa cile manipulation of atomic d ata is heavily underscored 
in iKallman and Palmeril (|2007l ). 

2.1. The Black Box Problem 

It is not clear how a similar ad-hoc query of APED 
could be formulated in XSPEC, nor how the results of 
such might be used within it for further analysis. One 
problem is that the use of APED in XSPEC is highly 
constrained, due to it being hidden, e.g., within the in- 
ternals of the apec model and identify commands. An- 
other obstacle is that high-level plotting in XSPEC is not 
generic: the plot and iplot commands are also opaque, 
in that they take their vectors from internal state rep- 
resenting the current data or model under inspection. 
Intimately tied to the semantics of ID spectral analysis, 
these commands may not be used until after a dataset 
has been loaded. 

While ISIS contains similar visualization commands 
specifically tailored to spectral analysis, the oplot func- 
tion shown above is part of a family of routines which 
allows one to create arbitrary image, scatter, histogram, 
and contour [over] plots from arbitrary data, indepen- 
dently of the current spectra being analyzed. This makes 
exploratory coding and visualization like 

isis> x = [PI/2: 2*PI: PI/100] 
isis> plot(x, cos(x)) 
isis> oplot(x, sin(x)) 

as natural in ISIS as it is in other interactive analy- 
sis sy stems such as IDL or PyRAF (|de La Pena et all 
2001). In XSPEC such dynamic creation of interpreted 
arrays and direct mathematical manipulation and visu- 
alization of them is more difficult, involving a melange 
of TCL code, XSPEC commands, intermediate files, and 
low-level QDP/PLT directives. 2 The issue is not that in- 
terpreted numeric arrays cannot be utilized in XSPEC, 

2 Or going outside of XSPEC to use tools like f v or XIMAGE. 
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Fig. 2. — Performance of IDL 6.1 (binary distribution) and S- 
Lang (statically linked), on \/b' 2 — Aac for arrays of various sizes. 

because the TCL extensions BLT and NAP (see next sec- 
tion) make this possible; nor does the problem lie with 
PGPLDT, since it provides more capabilities than XSPEC 
currently exploits. Rather, it is the XSPEC architecture 
which does not connect the two in a straightforward man- 
ner, leaving the user little choice but to look elsewhere 
for open-ended numerics and visualization. This opacity 
and disconnectedness is evident in other functional areas 
of XSPEC, notably the manner in which data are input 
&; managed (SJ) and how custom models are specified 

Echoing similar criticisms levied upon graphical inter- 
faces when comp ared to command lines ( Normanll2007t 
iBland et al.ll2007t ) , we collectively refer to these issues as 
the Black Box Problem: by hiding complexity to make 
common tasks easy, uncommon or novel tasks can be 
made difficult or impossible. 

The ease of use that has been a hallmark of XSPEC- 
written by astronomers to do things astronomers need, in 
a way natural to them — has served the community well. 
A challenge, though, is that as instruments and the data 
collected from them grow in size and complexity, caus- 
ing us to consider new questions and possibly develop 
new techniques to answer them, the Black Box Problem 
can engender You May Only! patterns of analysis, rather 
than foster rapid, ad hoc explorations of What If? sce- 
narios. More modular, configurable, and open implemen- 
tations (|Kiczalesl [l996'l can help resolve this tension, al- 
lowing applications to rapidly evolve to suit specific user 
needs while freeing their primary authors of the burden of 
coding and maintaining such enhancements themselves. 

3. HIGH PERFORMANCE NUMERICS 

Compact multidimensional numerics are a major ba- 
sis for the popularity of commercial toolsets such as IDL 
or MatLab. The innate capability of S-Lang in this re- 
gard was a primary motivator for its adoption in ISIS, 3 
and endows it with analytic expressiveness and scripting 
performance not equaled in XSPEC. 

As indicated in the earlier code fragments, complex 
mathematical abstractions may be stated concisely in S- 
Lang, without regard to whether they will operate upon 
scalars, vectors, multidimensional arrays, or some com- 
bination of each, and are computed with performance on 

3 Another motivator was wide availability: S-Lang is utilized 
in numerous open source projects and, in part by virtue of being 
bundled as a core component of every major Linux distribution, is 
available on millions of machines worldwide. 
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Fig. 3. — The ISIS mainO program is a thin ANSI C layer above the S-Lang interpreter, used primarily to establish hooks to modules 
and gather user input. Taking modularity to this extreme, where carefully orthogonalized components provide the bulk of capability, 
provides a clean and flexible implementation. Most modules may also be used outside of ISIS. 



par with commercial software (e.g., as in Fig. [21). In this 
section we discuss the more involved example of Fig. 01 
consisting of an orbital model implemented in pure S- 
Lang and taken "as is" from an MIT research effort The 
model was fit to a coarsely binned lightcurve (provid- 
ing an example of how ISIS can model non-spectroscopic 
data directly from in-memory S-Lang arrays, as discussed 
in [T4]), and represents a steady amplitude curve inter- 
rupted by an eclipse with a quadratic ingress and egress, 
with low-level emission d uring the eclipse also m odeled 
by a quadratic function. ((Trowbridge et al.ll2007f ). 

As a means of assessing the numerics and extensibil- 
ity of XSPEC we attempted to translate this model into 
TCL; for completeness we also made Perl and Python 
translations, since these languages are actively employed 
by astronomers in systems like PDL and PyRAF and so 
are useful contrasts for gauging the numerical capabili- 
ties of S-Lang. Because neither TCL , Perl, nor Python 
are intrinsically vectorized we used numerical extension 
modules for each conversion: BLT & NAP for TCL, PDL 
for Perl, and Numeric, NumArray, & NumPy for Python. 
The Python and Perl conversions were straightforward, 
with Python being the somewhat easier of the two; we did 
not complete the conversion to TCL, however, largely be- 
cause neither BLT nor NAP provided a clear equivalent 
to the where command or a means of using the results of 
such for array slicing. This model would therefore need 
to be recoded in a compiled language before it could be 
used in XSPEC. A plot of the performance of Perl 5.8.4 
and Python 2.4 implementations of this model, divided 
by the corresponding S-Lang 2.0.7 performance, is given 
in Fig. El 

The test ing me t hodol ogy behind Figs. [2] and [5] is de- 
scribed in iNobld (|2007f ). along with memory statistics 
and additional tests showing similar performance trends. 
Briefly, the datapoints in each curve are the mean times 
of 1000 invocations of the model on a given grid size 
(31 in all, from 1 to le6 bins); all codes were com- 
piled using GCC 3.3 with -03 optimization, and exe- 
cuted on a dual Athlon (1.8Ghz) machine running De- 
bian 3.1. Although not a comprehensive series of bench- 
marks, these results hint that the numerical engine of 
ISIS is among the strongest available. High performance 
scripting means that rapid development techniques — 
irrespective of language — can be applied to a broad scope 
of analysis problems, allowing the writing of compiled 



code to gradually become a last resort instead of the 
primary avenue of attack. S-Lang bears a strong re- 
semblance to C and IDL, arguably the most popular 
scripting language used by astronomers, and in fact we 



define orbitalClo, hi, par) 
{ 

variable a,c,wl ,w2 ,sl ,s2,s3,ml ,m2 ,m3,bl ,b2,b3, i,r=@lo; 



a = par [0] 

si = par [4] 

m2 = par [8] 

b3 = par [12] ; 



c = par[l]; wl = par [2]; w2 = par [3] ; 
s2 = par [5]; s3 = par [6]; ml = par [7]; 
m3 = par [9]; bl = par [10]; b2 - par [11] ; 



i = where C lo >= c-wl/2 and hi <= c+wl/2 ); 

r[i] - si * ((hi[i]+lo[i])/2)~2 + s2 * ( (hi [i] +lo [i] )/2) + s3; 
i = where( lo >= c+wl/2 and hi <= c+w2/2) ; 

r[i] - ml * ((hi[i]+lo[i])/2)~2 + m2 * (Chi [i] +lo [i] )/2) + m3; 
i = where C lo >= c-w2/2 and hi <= c-wl/2); 

r[i] - bl * (Chi[i]+lo[i])/2)-2 + b2 * ( (hi [i] +lo [i] ) /2) + b3; 

i = where ( lo >= c+w2/2 or hi <= c-w2/2) ; 
r[i] = 1; 

i=where((lo < c-wl/2 and hi > c-wl/2) or (lo < c+»l/2 and hi > c+wl/2)); 
r[i] = 0; 

i=where((lo < c-w2/2 and hi > c-w2/2) or (lo < c+w2/2 and hi > c+w2/2)); 
r[i] = 1; 

return a*r; 

} 

Fig. 4. — Pure S-Lang orbital mod el, fit by ISIS directly t o 
in-memory data arrays. As described in Trowbridge et al. (2007), 
the model represents a lightcurve of constant amplitude a, with an 
eclipse centered at c, with a width w2 from the start of ingress to 
the end of egress. The ingress and egress have a quadratic form 
(m and b parameters), and there is a quadratic "bounceback" (s 
parameter) with width wl. 



and colleagues have converted numerous IDL and Mat- 
Lab scripts to S-Lang for use in ISIS with relative ease. 



4. ARRAY-BASED INPUT 

As we found with the orbital model, converting such 
scripts to TCL for use in XSPEC would pose a consider- 
able challenge: although the primary interface of XSPEC 
is a scriptable interpreter in which multidimensional ar- 
rays may be created and mathematically manipulated — 
with the aid of the BLT or NAP — the results of such 
cannot be straightforwardly utilized for spectroscopy. 
The fact that the internal data tables of XSPEC are 
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Fig. 5. — Performance of orbital models implemented in Perl 5.8.4 
and Python 2.4, relative to S-Lang 2.0.7. TCL is not represented 
here because neither of its numerical extensions, BLT and NAP, 
offered a clear equivalent to the where () function. 

not exposed for direct population from the TCL inter- 
preter is another instance of the Black Box Problem; 
data may only be read from FITS files, and only via 
the data command or its INTEGRAL mission-specific 
variant SPIdata. There is no documented provision by 
which interpreted arrays may be used, for instance, to 
specify observed counts or responses. 

Reflecting a fundamental difference in approach, 
XSPEC is more static than ISIS, taking the position 
that extensive data preparation happens outside the 
application. An advantage of this approach is self- 
documentation: well-written tools record the path along 
which a FITS file travels as history keywords in its 
header. A drawback is the underlying implication that 
input data need little massaging during interactive anal- 
ysis; when the need for such data manipulation arises, 
the solution typically involves dumping XSPEC state to 
disk files, and/or running FTOOLS or other programs 
to generate new file products, then reloading these data 
back into XSPEC. 

This files-only data management paradigm can lead 
to slower performance and more cumbersome analytics 
(fJTJ H7A\i . It can also be an evolutionary disadvantage, 
i.e. by potentially limiting the pool of individuals able 
or willing to contribute new I/O codes to XSPEC. As 
exemplified by the implementation of the SPIdata com- 
mand, endowing XSPEC with the ability to directly read 
additional file or mission formats requires detailed mas- 
tery of its internals. This means ge neral-purpos e code 
gener ators like SWIG (|Beazlevl H9M ) or SLIRP (jNobld 
l2007f ) cannot be leveraged to automate the wrapping 
of I/O libraries and simplify the use of new formats 
in XSPEC. To foster the widest possible use, by de- 
sign such wrapper generators know nothing about the 
applications in which the bindings they create will be 
used. They emit code targeted to the scope of a scripting 
language, rather than application-specific C++ methods 
like SPIJData: : readO which is suitable only for internal 
XSPEC use. 

4.1. Towards Dynamic Data Management 

ISIS aims for a more dynamic and configurable ap- 
proach to data management. In addition to support- 
ing file-based input in the manner of XSPEC, but with 
ASCII in addition to FITS, ISIS also permits most facets 
of the modeling process to be specified directly from in- 
terpreted S-Lang arrays in memory, including the the- 



oretical and observed counts, ARF, RMF, and back- 
ground. 

The problem of augmenting spectroscopy with data in 
foreign formats is thus reduced from having to master 
XSPEC internals to merely being able to create S-Lang 
arrays from such files. This is within the reach of end 
users, not just application authors, particularly because 
automatic code generators can then be employed to sim- 
plify the creation of scriptable wrappers for the relevant 
I/O libraries. 

As an example of how these considerations can mat- 
ter in practi cal use, consider the HDF5 file format and 
I/O library (jFolk et all 1 19991 ). While FITS is the stan- 
dard format for archiving and distributing astrophysical 
observations, HDF5 has become the defacto standard for 
storing astrop hysical simu l ation s such as those generated 
by FLASH ((Frvxell et all 1200 ll ). Having the ability to 
easily compare and contrast observations with simula- 
tions, e.g., using simulation output as source model in- 
put, could foster more sophisticated analyses. We have 
explored such questions in ISIS as part of the HYDRA 4 
project, using SLIRP to generate the SLh5 module 5 for 
reading and writing HDF5 data directly to and from in- 
memory S-Lang arrays. The resulting objects may be 
sliced with S-Lang array manipulators or mathematically 
transformed in arbitrary ways ( fj3j) before further analy- 
sis, such as being treated as fit data or model data, or 
passed to 2D plotting or 3D volumetric routines for vi- 
sualization. This module also obviates the need for a 
conversion tool to migrate data from HDF5 to FITS for 
spectroscopy 6 . 

This spirit of imposing fewer constraints on how its in- 
ternal tables may be populated or manipulated leads to 
more flexible and mathematically diverse analysis. For 
example, consider the problem of grouping data to en- 
sure an adequate signal to noise ratio is obtained for each 
detector channel. With XSPEC data are grouped prior 
to input, usually with the grppiia tool. The assigned 
grouping persists for the life of the loaded dataset, and 
may only be changed by re-running grppiia outside of 
XSPEC, deleting the original dataset in XSPEC, and 
reloading it with the new grouping. With ISIS spec- 
tra may be dynamically rebinned in memory — using the 
functions rebin_data() , group_data() , or variants — 
with the associated dataset remaining intact. ISIS also 
provides options not available in the XSPEC grppiia 
paradigm, such as grouping by signal to noise ratio, or 
allowing datasets to be combined directly in memory, 
bringing to bear the full numerical power discussed in 
fJ3] and instead of shelling out to run tools such as 
mathplia, marf rmf , or addrmf — an approach of more lim- 
ited mathematical generality. ISIS also supports combin- 
ing non-linear (e.g. piled-up) data, which in general can- 
not be done with tools because of the model evaluation 
involved. 

5. CUSTOM MODELS 

In we detailed how the performance of S-Lang 
couples with the ability of ISIS to use purely inter- 

4 http://space.mit.edu/hydra 

5 http: / / space. mit . edu / exc / software / slang/ modules /slh5 

6 http://www.hdfgroup.org/RFC/fits2h5/fits2h5.htm describes 
preliminary efforts to go in the other direction. 
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preted models to provide an alternative to the tradi- 
tional method of using compiled codes as custom spec- 
tral models. This significant feature, not available to 
XSPEC users since it does not permit TCL procedures 
to be used as models, can encourage rapid experimenta- 
tion with short, highly analytic codes. These brief, self- 
contained scripts are easily exchanged among users, as 
they may be loaded immediately into ISIS from any di- 
rectory. This is in contrast to code that must be compiled 
into a shareable object then accessed from fixed locations 
and in conjunction with external description files, such 
as $LOCAL_MODEL_DIRECTORY and lmodel.dat are 
respectively used in XSPEC. 

Moving to the realm of compiled models, while version 
12 of XSPEC provides many improvements over version 
11 — notably support for C and C++, double precision 
numerics, and the initpackage automated model wrap- 
ping command — a number of limitations persist. To be- 
gin, using local models at all means one must first build 
XSPEC from source. Although HEASOFT generally 
builds well, this can still be daunting, and is unnecessary 
with ISIS as both interpreted and compiled user mod- 
els may be used from a binary installation. Next, model 
components in XSPEC must be designated as having a 
specific form, e.g. additive, multiplicative, convolution, 
etc. This too is unnecessary in ISIS, as it places no re- 
striction upon the computational form of a model — any 
conceivable mathematical function may be used. 

As XSPEC has been the defacto standard for so long, 
it is also easy for spectral model developers to code ex- 
pressly for XSPEC, by relying too heavily upon its inter- 
nal functions (such as udmget for memory allocation or 
xwrite for message output) when crafting models. When 
XSPEC was the only X-ray spectral modeling tool avail- 
able this was not a concern, but today it makes reusing 
models in other environments more difficult. For exam- 
ple, pulling the pexriv model out of XSPEC 11, which 
remains widely used, required 

-lxspec -lxspec_lfn -lxspec -lwcs 
-lxanlib -lreadline -lcfitsio -lpgplot 
-lcurses -ltermcap 

on the link line, plus the introduction of a "dummy" 
function to resolve an unused symbol name 
(|Markoff and Nowakl I2004D . Standing out here is 
the recursive use of -lxspec, and the need for auxiliary 
terminal management and plotting libraries that provide 
no numerical or physics contribution to the model. 
Although this situation is improved in XSPEC 12, these 
show that it is not enough to simply make source code 
available to the public: orthogonality is an important 
aspect of open and flexible software. To promote 
external reusability, code must also be separable into 
logically distinct units free of unwanted dependencies. 
These are core implementation principles of ISIS (Fig. 

5.1. Automated Model Wrapping 

While initpackage does help automate the use of cus- 
tom models in XSPEC 12, it is not a generic, application- 
neutral wrapper generator in the style of SLIRP or SWIG. 
The result is that custom modeling cannot be scripted in 
XSPEC with the same level of flexibility as in ISIS. For 
example, initpackage does not expose the routines it 



wraps to the top-level TCL interpreter, but rather makes 
them accessible only through the the XSPEC 
model command. Not being able to call models directly 
from TCL means the convenience of an interpreter can- 
not be leveraged when testing and using the models. 

This can be easy to overlook, because many model 
writers devise their own nominal tests in whatever com- 
piled language they used to write the model. However, 
it would be valuable for both writers and users of models 
if they could craft TCL commands or scripts to exercise 
them (in a more powerful and streamlined manner than 
the multiplexing tclout command, or faking a dataset) 
or pass their output to other features in the application 
for further numerical processing. Consider Fortran com- 
mon blocks, for instance, and the XSPEC warmabs model 
in particular: after evaluation the ewout block in this 
model contains a list of the strongest lines, sorted by el- 
ement and ion. Wrapping warmabs with SLIRP makes 
the content of this and every other common block in the 
model accessible to ISIS as S-Lang variables. 7 This pro- 
vides scientists another means of accessing the internals 
of a code, without needing to master the internals of the 
application for which that code was initially written. 

In addition, initpackage wraps only the outermost 
interface routine of a model: if the spectrum returned by 
a model is actually computed in several steps by call- 
ing additional routines, those lower level routines are 
not exposed by initpackage for use in XSPEC outside 
the model evaluation. As an example of how exposing 
the low level routines could be useful, we consider the 
pshock and vpshock models. Internally, both rely upon 
the lower-level ionseqsO routine to calculate nonequi- 
librium ionization ionic concentrations. In response to 
a collaborator (Ji 2007, priv. comm.) who wished to 
obtain these ionic concentrations independently, we used 
SLIRP to wrap ionseq.f in a matter of only minutes, 
which allowed ionseqsO to be called directly from a 
S-Lang script in ISIS. 

The jet model of iMarkoff et all (|2005t) provides an- 
other good example. The output spectrum is summed 
from 4 individual components (disk, comptonization, 
synchrotron, and synchrotron self-comptonization spec- 
tra), each computed by distinct routines within a single 
Fortran source file. To analyze or visualize the inde- 
pendent contribution of each component it is necessary 
to isolate each from the total flux. To achieve this the 
model can be executed in different modes, one of which 
will execute write statements to output component con- 
tributions to disk files as they are computed. Because our 
SLIRP wrapper for this jet model makes every routine 
within the Fortran file visible to the top-level S-Lang in- 
terpreter, not just the outermost model routine, the com- 
ponent fluxes can in principle now be accessed by mak- 
ing the relevant routine calls, or accessing the associated 
common blocks, directly from ISIS. To our knowledge the 
only way to achieve a similar result in XSPEC would be 
to wrap the code twice, once with initpackage to make 
the custom model routine visible to the model command, 
and again as a TCL extension module to expose the re- 
maining routines to the TCL interpreter. Tools like f tcl 

7 Common block values may also be modified using regular S- 
Lang assignment expressions. 
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or critcl 8 can simplify bindings generation in the lat- 
ter case, but not automate it to the level that SLIRP 
does; it is also unclear whether they support a range of 
features seen in general scientific codes, such as common 
blocks, string and multidimensional arrays, or complex 
datatypes. 

Using initpackage for models which call external li- 
braries can also be problematic. For example, collabora- 
tors are extending the above jet model with codes that 
call GNU Scientific Library routines, but initpackage 
documents no mechanism by which the GSL can be 
linked in at build time. Following compiler convention, 
this is achieved with SLIRP by specifying -lgsl on the 
command line. 

Finally, functions wrapped by SLIRP can be automat- 
ically vectorized, allowing them to operate over entire ar- 
rays in a single call, and at the speed of compiled C code 
instead of using slower, interpreted looping constructs. 
Vectorized wra ppers can also be tuned for parallelization 
with OpenMP (|Nobld I2007T ) . allowing scientists to take 
better advantage of their multicore machines during ISIS 
analysis. To our knowledge autogenerated vector parallel 
wrappers are currently unique to SLIRP, and therefore 
inaccessible in XSPEC. 

6. PARALLEL AND DISTRIBUTED COMPUTATION 

Parallel computing is not new, but to this day few 
astronomers employ parallelism for standard problems 
in data analysis. To provide a quantitat ive sense of 
this a ssertion relative to X-ray spectroscopy (|Noble et al.l 
2006), we performed the following full text searches on 
all p ublished papers indexed in the ADS (|Kurtz et al.l 
[1993D by September of 2005. Extra keywords were m- 



Keywords Number of Hits 
parallel AND pvm 38 
message AND passing AND mpi 21 
xspec 832 
xspec AND parallel AND pvm 
xspec AND message AND passing AND mpi 



TABLE 1 

Published references to parallelism and XSPEC, as 

INDEXED IN ADS THROUGH 2005. 



eluded with PVM and M PI (the Message Passing In- 
terface, Grop p et al.lll999f ) so as to cull false matches 
(e.g. with the Max Planck Institute). Queries in ADS 
on other modeling tools, or with other search engines 
such as Google, all yielded similar trends: astronomers 
and astrophysicists have employed parallel computing, 
but mainly for highly customized, large-scale problems 
in simulation, image processing, or data reduction. Even 
though a majority of papers published in observational 
astronomy over recent decades result from fitting models 
within established software systems, virtually no one is 
employing parallelism to do so, especially in the interac- 
tive context. 

As discussed in iNoble et al.l (|2006f ) and earlier in SJTJ 
for several years PVM has been used in ISIS 9 to ap- 

8 http://ftcl.sourceforge.net, |http://wiki.tcl.tk/2523| 

9 PVM was used due its longstanding tolerance of faults on het- 
erogeneous clusters of workstations, but in principle an MPI mod- 
ule could be used just as easily within ISIS. 



ply pools of machines to coarse-grained calculations that 
do not fit within the compute space of one worksta- 
tion. Consider relativistic Kerr disk models, for exam- 
ple. Historically, implementors have opted to use pre- 
computed tables to gain speed at the expense of limit- 
ing flexibility in searching parameter space. However, 
by recognizing that contributions from individual radii 
may be computed independently the model has been 
parallelized i n ISIS to avoid this tradeoff (A. Young, 
priv. comm.. lBrenneman and Reynol ds 2006). Likewise, 
the aforementioned jet model can be expensive to com- 
pute, particularly when calculating error bars: generat- 
ing 90% confidence limits for 12 free parameters, at the 
very coarse tolerance of 0.5, required 4 days on a single 
2.66 GHz Intel Core 2 Duo processor. To increase per- 
formance we assigned the confidence limit search to 12 
Intel Xeon 3.4GHz processors 10 within a PVM. This re- 
duced the runtime at 0.5 tolerance to under 24 hours, a 
greater than 75% speedup; it also allowed us to discern 
finer features in parameter space by increasing the toler- 
ance resolution by a factor of 500, to 0.001, while keeping 
the overall runtime to 50 hours, or approximately half of 
the serial runtime at 0.5 resolution. 

Temperature mapping is another problem that was 
straightforward t o par allelize with ISIS. For instance, 
iWise and Houckl (|2004D provides a map of heating in the 
intracluster medium of Perseus, computed from 10,000 
spectral extractions and fits on 20+ CPUs in just several 
hours. Additional efforts have also led to improvements 
in related areas of research, such as pvm_xstar, a paral- 
lelizing wrapper for XSTAR which has made it feasible 
for us to probe thousands of photoionized gas physical 
scenarios in the time it has previously taken to compute 
only a handful of such models (Noble & Ji, in prep.). 

At the other end of the architectural scale, we have also 
shown that ISIS can make transparent us e of OpenMP 
to exploit shared memory multiprocessors (|Noblell2007t ). 
This is especially relevant in light of the emergence of 
multicore architectures: soon most astronomers will have 
parallel computers on their desktops, but few astron- 
omy applications are poised to take advantage of them. 
Analysis systems which do not embrace parallelism can 
process at most the workload of only 1 CPU, result- 
ing in a dramatic 1/n underutilization of resources as 
more CPU cores are added. However, astronomers are 
well versed in scripting, particularly with very high-level, 
array-oriented numerical packages like IDL, PDL, and S- 
Lang, to name a few. They combine easy manipulation 
of mathematical structures of arbitrary dimension with 
most of the performance of compiled code, with the lat- 
ter due largely to moving array traversals from the inter- 
preted layer into lower-level code like this C fragment 

case SLANG_TIMES: 

for (n = 0; n < na; n++) 
c [n] = a [n] * b [n] ; 

which provides vectorized multiplication in S-Lang. This 
suggests that much of the strength and appeal of nu- 
merical scripting stems from relatively simple loops over 
regular structures, making them ripe for automatic par- 
allelization. This pattern was exploited in SLIRP and 
S- Lang to effec t the OpenMP parallelizations described 
in (|Noblell2007lh 

10 Using new versions of the cljnaster and cl.slave scripts 
described on the ISIS website. 
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We believe that ISIS is the only general purpose spec- 
troscopy system in which such a range of parallelism — 
from single processors on multiple machines to multiple 
processors on single machines — has been demonstrated. 
In both cases speedups were obtained without exposing 
parallelism at the ISIS application level. For instance, 
the same serial implementations of spectroscopic mod- 
els have been used for both single- and multi-processor 
execution. This minimizes two traditional barriers to 
the use of parallelism by non-specialists: learning how to 
program for concurrency and recasting sequential algo- 
rithms in parallel form. We believe these considerations 
are important because the emerging ubiquity of multi- 
core architectures, combined with the ever-growing size 
of datasets and analysis complexity, makes the regular 
use of parallelism in astronomy not a question of if it 
will occur, but rather one of merely when. 

7. BEYOND ID SPECTROSCOPY 

Data from modern telescopes are getting larger and 
more detailed, with the use of multiple datasets from 
multiple missions becoming commonplace. Making sense 
of it all often requires techniques more sophisticated 
than traditional plots or images. Canned data reduc- 
tion threads, while an important piece of the puzzle, 
can only go so far. Data openness and architectural 
modularity (Fig. [3J make it easy to push ISIS beyond 
its original mission of ID spectroscopy to address this 
broader set of analysis problems. As we illustrate here, 
it has become unnecessary to use entirely separate appli- 
cations (as Xlmage, XSelect, or Xronos are used along- 
side XSPEC) or be constrained by a strictly file — » tool 
— y file model, in order to supplement spectral modeling 
with, for example, advanced filtering, imaging, or timing 
analysis. For each of the examples shown here it is not 
clear how a similar result might be obtained so directly 
within XSPEC. 

7.1. Timing Analysis 

The optional SITAR module 11 endows ISIS with tim- 
ing analysis capability, obviating the need to use a sep- 
arate timing application such as XRONOS. The power 
spectrum in Fig. [5] was generated entirely in ISIS: the 
data were read, the FFTs were performed and aver- 
aged, the Power Spectrum was logarithmically binned 
over Fourier frequency, the constant + two Lorentzians 
model was fit, and the results plotted, operating directly 
upon arrays in memory, all without ever leaving the pro- 
gram. 

7.2. Modular Imaging with S-Lang Numerics 

Many excellent imaging tools are available to as- 
tronomers, but it is impossible for any one of them to 
do everything. Here again, the extensibility and modu- 
larity of the ISIS paradigm helps avoid the fate of "doing 
nothing" while waiting for the implementation of new 
features desired in one's work. In such cases it can be 
expedient to craft new modules which add missing fea- 
tures, or make certain functionality more easy to incor- 
porate into modeling and analysis. 

For example, consider Fig. [7l drawn from Chandra 
observation 4800 of interacting galaxy pair NGC7714, 
and the following series of commands: 

11 http://space.mit. edu/CXC /analysis/SITAR 
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Fig. 6. — Power Spectrum of X1820-303, generated from the 
PCA in RXTE observation P10075 (data set 10075-01-01-02). 

isis> require("ds9") 

isis> require("gsl") 

isis> image = ds9_get_array () 

isis> hist = sum(image, 0) 

isis> range = [440:680] 

isis> hplot (range- 1 , range, hist [range] ) 
isis> xa = [440:680:4]; ya = hist[xa] 
isis> smoothed = interp_cspline (range, xa, ya) 
isis> oplot (range, smoothed) 

First the S AOds9 and GNU Sc ientific Library exten- 
sion modules (jPrimini et al.l l2005h are loaded; we show 
this explicitly for didactic purposes, but ISIS can be con- 
figured to load either module automatically when the 
given functions are invoked. The 1024x1024 image is 
then retrieved directly into a prope rly byteswapped 2D 
S-Lang pixel array, using an XPA (|Mandel et al.|[l995[) 
binary transfer instead of intermediate file I/O. This im- 
age is collapsed along its X axis using the native S-Lang 
sum function, to create an intensity histogram plot. The 
GSL cubic spline function is then called to smooth the 
brightest portion of the intensity histogram, interpolat- 
ing over every fourth point therein, and finally we over- 
plot the result (dotted red line). Although the task here 
is relatively straightforward, it again shows how open- 
ended analysis objectives can be achieved by weaving ex- 
isting tools together in new ways, using an array-based 
interpreter as the thread. DS9 is extended beyond its 
essential role as a qualitative display tool and into the 
realm of quantitative analysis, while the ISIS user is able 
to exploit the imaging capabilities of DS9 within inter- 
active or scripted analysis. 

Another example is evt2img, 12 a simple guilet 13 which 
combines the histogram and Gtk modules to provide 
an interactive mechanism for creating 3-color images di- 
rectly from event lists. Images are created in evt2img by 
defining 3 energy band filters, binning the events selected 
by each filter with the hist 2d function, and overlaying 
the resulting red, green, and blue monochrome images 
within a Gtk display window. As shown in Fig. [8j a 
useful feature of evt2img is its ability to plot the energy 

12 http:/ /space. mit.edu/cxc/software/slang/modules/hist/evt2img. html 

13 This term is used in Noble ( 2005|) to refer to graphical applets 
embedded within a primarily command-line application, and typ- 
ically coded in a scripting language, allowing the use of graphical 
interfaces when convenient while avoiding an exclusively graphical 
interface. 
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Fig. 7. — ACIS image from 2004 Chandra observation of NGC7714, with corresponding square and smoothed pixel intensity histograms. 




Fig. 8. — Interactive 3-color image creation in evt2img, using the level-2 event file acisf00120N001_evt2.fits from Chandra observation 
120 of supernova remnant E0102-72. One may pan around (by clicking to center the image), zoom in and out, and set various scaling 
properties by clicking on the corresponding buttons. The image in the left column shows a fair amount of high energy background noise, 
as evidenced by the blue background pixels. These were removed in realtime by adjusting the colored energy band sliders that define the 
RGB levels (bottom panels), to yield the improved image in the right column. 
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spectrum as a ID histogram in order to tune the color 
band filters in real time, simply by adjusting the indi- 
vidual red, green, and blue sliders. For interactive ex- 
ploration this method is faster and more intuitive than 
the traditional file — ^ tool — > file approach, and produces 
no temporary file litter while experimenting with color 
assignment filters. Evt2img may be run standalone from 
the operating system prompt or as a function in ISIS, 
and in the latter case allows event data to be input di- 
rectly from in-memory interpreted arrays in addition to 
traditional event files. The HYDRA project at MIT pro- 
vides a wealth of more sophisticated examples 14 of how 
advanced imaging can be tied more directly to numeri- 
cal modeling and analysis in ISIS. Under the auspices of 
the NASA AISRP program, a broad suite of 2D and 3D 
fitting, geometry, and visualization routines have been 
developed, e.g. to do forward folding and comparison 
of models with 2D event-based data sets. These are de- 
scribed in detail online, but are briefly illustrated here in 
the context of an analysis of cavities in Hydra A, using 
the Chandra observation 4969. A model is defined by 
combining traditional spectral components (e.g. mekal 
and powerlaw) with 3D geometric components (e.g. an 
AGN modeled as a sphere). The fitting is performed di- 
rectly in ISIS, as is the generation of the residual, data, 
and model images, and 2D and 3D model component 
projections (Fig. [9]). 

7.3. Volume Visualization 

Astrophysical observation and simulation are in the 
midst of a transition beyond ID spectra and 2D images, 
and into the realm of three-dimensional phenomena. A 
number of astronomy software tools exist which enable 
visualization of so-called 3D data cubes, but a problem 
shared by many of them is that they are limited to dis- 
playing one 2D slice at a time, optionally in series as 
an animation. Here we consider a 99 spectra data cube 
generated by CUBISM 15 from Spitzer observation 3310 
of Cassiopeia A, with dimensions RA, DEC, and A. To 
identify where emission is strongest in the spatial and 
wavelength domains, the entire FIT S datacube can be 
passed directly to volview (Fig. [TP)) 

isis> require ("volview") 

isis> cube = f its_read_image("casa_lll_sl2 . f its") 
isis> volview(cube) 

This visualization makes it instantly clear that the 
clumpy regions correspond to bright emission at fairly 
specific wavelengths. The volview g uilet is our interface 
to th e Volpack rendering library (|Lacroute and Levovl 
119941) , which, although somewhat dated, is small, has no 
external dependencies, requires no special hardware, and 
is very fast. The shear- warp factorization algorithm in 
Volpack has been generally recognized as the fas test ren- 
dering technique available (Mei finer et al.|[200fj| ). a cru- 
cial factor for interactive analysis. In contrast to high- 
end tools like ParaView and VISIT 16 , volview provides 
a simple, low buy-in path to volume rendering and is 
actively used in the HYDRA project. 17 . 

14 http://space.mit.edu/hydra/E2D_demo/e2d_demo.html 

15 http:/ /ssc. spitzer. caltech.edu/archanaly/contributed/cubism 

16 http://www.paraview.org, |http: //www. l lnl.gov/visit 

17 http:/ /space. mit.edu/hydra/v3d. html 



7.4. Visual Correlation and Multidimensional Filtering 

Having the ability to cut, visualize, and correlate data, 
in complex ways and from multiple missions, is invaluable 
to analysis. This exploratory process ultimately seeks to 
derive sets of constraints C — {Co,...,C„} upon input 
data D by iterating through a series of models, compar- 
isons to data, and refinements of assumptions and model 
parameters. Because its analytic process does not en- 
compass whole- array numerics (Sj_5j an iteration of 
this cycle in XSPEC can involve dumping application 
state to disk, followed by the execution of multiple tools 
such as f select or feale to transform or cut file data, 
possibly f v or XIMAGE to visualize filtered data subsets, 
and XSPEC to incorporate the results back into analysis. 
This process creates temporary file litter products which 
can quickly become difficult to manage, and requires slow 
disk I/O passes over files when applying each unique set 
of filter constraints. Other limiting factors are that it re- 
stricts the scope of exploration to data expressed in the 
FITS file format, and that TCL-based I/O in tools like 
f v does not scale well to datasets containing millions of 
events. 

In contrast, Where (|Nobld I2005T ) . a graphical ex- 
tension of the S-Lang where array slicing function, 
unifies the constraint cycle by enabling each phase to 
be performed within a single application. The result 
can be an intuitive, faster, and more powerful alter- 
native to file-based data mining. By supporting the 
use of interpreted S-Lang arrays ISIS & Where make 
it easy to combine data from multiple sources and for- 
mats, not just FITS files, and examine them in natu- 
ral ways, as well as foster scalability. Where has been 
used to simultaneously mine hundreds of observations 
from multiple telescopes, e.g. for evidence of transi- 
ti ons between the so ft and hard states of Cygnus X- 
1 (jNowak et al J 120051 ) . correlate model parameters with 
fit results — directly in memory from doz e ns of fits — for 
score s of observations (IWilms et all 120061 : iMarkoff et al.l 
l2007t iNowak et al.l 12008 ), and q uickly corroborate col- 
league n3Stihs^Hein____t_^ 120071 ) . 

Filtering in Where amounts to manipulating regions of 
interest on plots generated from S-Lang arrays (Fig. [TTj) . 
with no syntax required and the effects upon any combi- 
nation of vectors automatically visualized for inspection 
(Fig. [Tz!]) . This approach reveals data correlations that 
can be difficult and time-consuming to ferret out with 
tool-based techniques. New data vectors may be created 
on the fly and with no additional I/O overhead, using 
anything from simple arithmetic combinations of existing 
vectors to any mathematical transformation that can be 
specified in S-Lang or imported from external C, CH — h, 
or Fortran codes. 

In contrast, file-based filtering tools require the use of 
syntax which may conflict in subtle ways from package 
to package. Specifying mathematical operations to such 
tools, e.g., in the form of quoted Unix shell syntax, can be 
tedious and cumbersome, and does not approach the ex- 
pressive power (consider recursion, for example) or per- 
formance of ISIS numerics. As an illustration, consider 
the use of calculator tools for the discriminant computa- 
tion in Sjjl the 1-million element S-Lang array datapoint 
in Fig. [2] corresponds to a runtime of ca. 0.15 seconds: 



isis> a = [l:le6+l] ; b 
isis> tic; d = sqrt(b~2 - 



= 3*a; c = 2*a 
4*a*c) ; toe 
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Fig. 9. — Images created in ISIS by HYDRA Event-2D and Source-3D routines, while analyzing cavities within the Chandra observation 
4969 of Hydra A. Top: residuals, data, and model. Bottom: 2D and 3D projections. 




Fig. 10. — Entire datacube from Spitzer observation 3310; the two clumpy areas are instantly recognizable as regions of strong emission. 
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0.151172 

Using tools to perform similar operations upon files 

fcalc in out d "sqrt(b~2 - 4*a*c)" 

ftcalc in out d "sqrt(b~2 - 4*a*c) " 

dmtcalc in out expression="d=sqrt (b~2 - 4*a*c)" 

(from a locally compiled -02 distribution of HEASOFT 
6.1 and a CIA03.3 binary distribution, respectively) was 
consistently 1 to 2 orders of magnitude slower: roughly 
1.8 sec for fcalc, 2.3 sec for ftcalc and 70 sec for 
dmtcalc. If we include the time to write 

isis> s = struct{a,b,c}-; s.a=a; s.b=b; s . c=c 
isis> f its_write_binary_table("in" , "arrays" ,s) 

the arrays to disk and then read them back in 

isis> d = f its_read_table("out") .d 

the performance penalty of the tool approach is even 
greater. Moreover, the output product of each tool is 
not directly useful: to be visually inspected or used in 
further analysis, for instance, it first needs to be loaded 
into another program (e.g. f v, or XSPEC), incurring ad- 
ditional I/O and application overheads that are not seen 
in ISIS because its result arrays may be immediately ma- 
nipulated or passed to subsequent computations. 

Shared memory can, in principle, mitigate the disk I/O 
cost, but in this case it did not help: instructing ftcalc 
to write to shmem: //hi consistently resulted in runtimes 
of nearly 3 minutes, while the CIAO dmtcalc tool would 
not permit the creation of a shared memory FITS table. 
Even if shared memory were faster than files in this case, 
the point raised earlier in Sj3] still remains, namely that 
XSPEC documents no clear provision though which such 
generic data arrays may be utilized in analysis. It must 
also be noted that few, if any, file-based transformation 
tools are extensible. If we wished to use a hypergeometric 
function in VWhere it is as simple as loading the GSL 
module with require ("gsl") and calling the relevant 
function. If the mathematical operations required for 
their research are not supported, tool users would have to 
either make an enhancement request and wait or create 
their own solution. 

7.5. Aside On Reproducibility 

We have been refining the approach to analysis es- 
poused in this paper for much of the past decade. Dur- 
ing that time, one of the more persistent concerns we 
have privately encountered is that it can lead to dimin- 
ished reproducibility, particularly in contrast to the file 
—> tool — ^ file model. 18 Reproducibility is a cornerstone 
of science, and remains a t opic of debate in wider circles 
(|Collinsl[l992T: lGilesll2006f) . but is not treated in depth 
within the astronomy literature. We do not attempt 
to fill that gap here. Rather, we aim only to address 
the perception that configurable, interpreter-based meth- 
ods compromise reproducibility relative to file-based tool 
methods, and hope that this may contribute to a more 
complete treatment of reproducibility elsewhere. 

Central to reproducibility is the recording of history. 
Many tools assist that process by annotating modified 

18 This is relevant to the overall paper because it is the dominant 
means through which data are prepared for analysis in XSPEC, but 
applies to other analysis packages as well. 



files with FITS history keywords. This is of clear utility, 
especially when tracing pipelines and other well-defined 
data reduction procedures. For open-ended analysis, 
however, we do not believe it is superior to the forms 
of history recorded by full-fledged analysis applications. 
Consider what is being captured in history records writ- 
ten by tools: each keystroke of the command used to 
invoke the tool. This capability is not unique to tools. 
XSPEC and ISIS record keystroke history by virtue of 
their GNU readline command recall, editing, and log- 
ging capabilities, as do many other systems. Focusing 
on keystrokes alone, though, obscures a larger point: re- 
gardless of whether one prefers logs or header keywords, 
indiscriminately long lists of commands typed are of little 
value without some sense of their relevance to publish- 
able results. 

In the end what matters most is that results may be 
regenerated so that conclusions may be plausibly con- 
firmed by others, rather than having every bump or 
wrong turn along the way reproduced in high fidelity. 
Scripts, the logical endpoint of our interpreter-based ap- 
proach to analysis, confer this conceptual prioritization 
by making explicit the data and algorithms of greatest 
significance. Such scripts arise in tool-based analysis as 
well, only they tend to be expressed in system-oriented 
languages like Bourne shell or Perl, rather than intrinsi- 
cally whole-array numeric languages like S-Lang or IDL. 
It can be argued, then, that scripts lead to higher forms 
of duplicability than FITS history records alone. They 
are also easier to annotate with additional commentary. 
We therefore conclude that that tool- and interpreter- 
based approaches to analysis are approximately equiva- 
lent in the degree to which they facilitate reproducibility. 
Care must be still taken when "feature creep" introduces 
incompatibilities that make the use of older scripts prob- 
lematic with newer software versions, so it is important 
that version information be recorded and that older soft- 
ware remains accessible on the internet. 

8. CONCLUSION 

Progress in science can be measured by our ability to 
pose increasingly advanced, open-ended questions and 
address them with flexible techniques of commensurate 
sophistication. Since the age of Newton, one implication 
of this is that scientists must also practice mathematics, 
and since the age of Turing it has also meant they must 
practice programming. 

In this paper we have compared two open-source spec- 
tral analysis applications, XSPEC and ISIS, in an at- 
tempt to gauge how their scientific and mathematical 
reach may be extended with custom programming. Con- 
trasts between the two have been drawn from the con- 
text of current research efforts utilizing high performance 
computation, numerical modeling, atomic physics, visu- 
alization, automated code generation, and data manage- 
ment. We have demonstrated how these have led to the 
incorporation of new analytic techniques in ISIS, in ways 
that are either unexplored or problematic for the current 
XSPEC architecture and its associated file — ► tool — » file 
model of analysis. 

XSPEC has been of tremendous value to the X-ray 
community, continues to be actively developed, and has 
a strong history of community enhancement via local 
models (and to some extent, TCL/TK scripts). How- 
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ever, we have argued that the top-level simplicity of the 
XSPEC interface, long and rightfully one of the pillars 
of its appeal, can shroud much of its internal computa- 
tional and data handling mechanisms. This in turn can 
render XSPEC less adaptable — by the typical user — for 
evolving research needs. Commands which operate as 
black-boxed common denominators of analysis, and per- 
mitting only file-based data input, may not be enough 
to probe some of the more computationally challenging 
problems facing astronomers. 

We conclude that analysis applications such as ISIS, 
endowed with interpreted whole-array numerical capabil- 
ities and an open, modular, and scriptablc architecture 
designed expressly for high configurability, are more fa- 
vorably equipped to support ad-hoc research needs while 
not appreciably compromising reproducibility. Origi- 
nally envisioned as a tool for Chandra gratings spec- 
troscopy, ISIS has heavily influenced the development 
of additional Chandra analysis software, while also re- 



ceiving NASA AISRP funding to continue its evolution 
within the aforementioned HYDRA project. Although 
some of the ISIS capabilities we've emphasized do exist 
in other astronomy software, we are unaware of any pub- 
lications demonstrating how similar breadths of flexibil- 
ity and computational power have been collected under 
the umbrella of a single open-source analysis application 
and brought to bear on published research in spectral 
analysis and X-ray astronomy in the manner discussed 
here. 
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